Overall looks great 👍

It the use of QLatin1String instead of QString::fromLatin1 for stylistic reason ?

It the use of QLatin1String instead of QString::fromLatin1 for stylistic reason ?

Yes, I just chose QLatin1String because it indicates that it is simply a constant definition and it is not a conversion.

I could not test it (just the compilation), so it would be great if you could test it on Linux as described here.

Thanks for the detailed explanation. I will test tomorrow and then move forward with creating a new release.

Would it be possible to merge this branch ?
It would simplify my work which uses slicer python interpreter: https://discourse.slicer.org/t/python-interpreter-arguments-containing-special-characters/33466

Any feedback ? @jcfr

This is still a problem - https://discourse.slicer.org/t/patientname-and-rus-language-trouble/28870/9

Once continuous integration is fixed, the branch associated with this pull request will be rebased.

Related pull requests:

• COMP: Fix GitHub workflow using current "macos-12" runner #129
• COMP: Fix appveyor package upload by using "Python38-x64" instead of "Python27-x64" #130
• COMP: Fix setup of CircleCI python env. used to upload package #131
• COMP: Update Appveyor ensuring latest version of scikit-ci-addons is installed #132
• COMP: Attempt to fix restoration of cache in upload job #133
• COMP: Update appveyor secure env. value associated with GITHUB_TOKEN #134

I've added a fix that also fixes passing special characters in command-line arguments and fixes the issue of not being able to launch Slicer in a path that contains special character (Slicer/Slicer#8229).

@lassoan It looks like the mac build timed out. Perhaps this can be tested offline to ensure that the changes recommended are ready for inclusion.

Various CI fixes are needed here. I pushed updates that resolved the testing on macOS as seen by the successful macos-13 status check. The "macos-12" status check needs to no longer be a required status check as it will no longer get run as macos-12 github runner was removed at the end of 2024.

FYI: ```
cmake : CMake Error at CMakeLists.txt:21 (cmake_minimum_required):
At line:3 char:1

• cmake `

•   + CategoryInfo          : NotSpecified: (CMake Error at ...imum_required)::String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
  
  CMake 3.16.3 or higher is required.  You are running version 3.16.2
  

1.  The quickest would be to modify the change for minimum cmake version ```cf2bf431 (Hans Johnson                  2025-06-19``` to cmake_minimum_required(VERSION 3.16.2), 
2. OR --  or move the CI forward to VS2019.  (might be a lot of work to get a QT5 version for VS2019
3. OR -- install cmake > 3.16 manually in the VS2017 appveyor image
```yaml
init:
  - ps: |
      $cmakeVersion = "3.27.9"
      $cmakeUrl = "https://github.com/Kitware/CMake/releases/download/v$cmakeVersion/cmake-$cmakeVersion-windows-x86_64.zip"
      Invoke-WebRequest $cmakeUrl -OutFile "cmake.zip"
      Expand-Archive cmake.zip -DestinationPath "$env:USERPROFILE\cmake"
      $cmakeBin = "$env:USERPROFILE\cmake\cmake-$cmakeVersion-windows-x86_64\bin"
      $env:PATH = "$cmakeBin;$env:PATH"
      [System.Environment]::SetEnvironmentVariable("PATH", $env:PATH, "Process")
      cmake --version
     ```
     
Personally, I'm most in favor of option 3 then option 1, and least favorite is option 2.  

@jamesobutler I made some naiave attempts to fix CI, but it will like require someone with passwords to re-create a new docker image.

I've isolated the CI failures in : #136

Perhaps we could decouple the "non-ASCII characters" fixes from the "CI failures"

There seems to be a dependence on https://github.com/jcfr/qt-static-build. Perhaps that project should be moved to commontk or Slicer organizations.